1. Field of the Invention
The present invention relates to a packet receiving apparatus and packet transmission method used for packet transmission, and more particularly to a packet receiving apparatus and packet transmission method that decompress headers that have been compressed and transmitted.
2. Description of the Related Art
Among the most common protocols (communication procedures) presently used to transmit packets on the Internet are the RTP (Real-time Transport Protocol), UDP (User Data Protocol), and IP (Internet Protocol). In packet transmission, these protocols are commonly used in combination, and besides, these protocols have been standardized by the IETF (Internet Engineering Task Force).
In each of the above protocols, information is added as described below to transmission data for a header to form a packet. That is, by RTP, a sequence number (hereinafter “SN” when necessary), which denotes the order of data, and time stamp (hereinafter “TS” when necessary), which is the time information, are added to data to form an RTP packet.
Next, by UDP, the port number of the receiving side is added to an RTP packet to form a UDP packet. Furthermore, by IP, the Internet address (IP address) of the receiving side is added to a UDP packet to form an IP packet. The IP packet is transmitted to the receiving side.
Of these headers added by RTP, UDP, and IP, the TS and SN vary every time a packet is transmitted and therefore are dynamic information, whereas the rest of information is static information (STATIC information) that becomes constant once transmission begins.
A header like this is given for each protocol, and so when several protocols are used in communication, the header portion becomes long and the packet transmission rate decreases. For this reason, there are header compression methods that compress the header and then transmit a packet to improve the packet transmission rate.
The compression method for each header added by RTP, UDP, and IP is prescribed by the IETF in RFC (Request for Comments) 2508. The header compression methods prescribed in RFC2508 are principally for packet transmission on a wired network such as the Internet.
In contrast, one header compression method presently proposed by the IETF for wireless packet transmission such as used in a cellular phone network is the ROHC (RObust Header Compression). This header compression method, noting that the rate of error occurrence tends to be higher in a wireless network than in a wired network, features a high error resiliency for the errors that occur during transmission.
Also, because the band frequency that a wireless network can make use of is narrower than that of a wired network, ROHC sets a higher header compression rate than the compression methods prescribed in RFC2508. ROHC is prescribed by the IETF in RFC 3095.
In ROHC, there are two types of headers as shown in FIGS. 1(a) and (b), each respectively refereed to as the non-compressed (IR) packet and compressed (SO) packet. The header of an IR packet shown in FIG. 1(a) contains parameters that do not vary in the course of communication (IP addresses, port numbers, etc.: static information), parameters that vary in the course of communication (SN, TN, etc.), and CRC (Cyclic Redundancy Check) bits that check as to whether the header, when decompressed on the receiving side, has been correctly decompressed.
The static information, SN, and TN are often transmitted at predetermined intervals. The compressed packet shown in FIG. 1(b) does not contain an IP address, port number, TS, and Δ TS (TS increase), but contains a compressed sequence number (hereinafter “SN′” when necessary) and CRC bits. The SN′ is indicated with lower several bits of the original 16-bit SN.
To be specific, ROHC compresses a header as follows. That is to say, a non-compressed header containing an IP address and port number is not transmitted by every transmission unit, but is transmitted at predetermined intervals. When a consistent pattern appears between the SN increase and TN increase, the SN alone is transmitted, and the TS increase is calculated from the SN increase on the receiving side.
With respect to the SN, furthermore, only lower several bits are transmitted in an SO packet, and only when a carry occurs the complete bits of an SN is transmitted. In this case, the transmitting side compresses a header with reference to referential information called context, whereas the receiving side decompresses the header by using the same context as the one used by the transmitting side. The referential information here indicates previously transmitted header information.
To be more specific, the method for generating an SN′ by selecting the lower bits of an SN will be explained in detail with FIG. 2. First, because it is not possible to transmit only the lower bits in packet 1, a complete SN of 16 bits “0000 0000 0000 0001” is transmitted in an IR packet. Following this, the transmitting side transmits in sequence packet 2 and packet 3. However, because the upper bits (bit 1 to bit 12) do not vary between neighboring packets, only the lower 4 bits (bit 13 to bit 16) are transmitted. By making reference to the context, the receiving side can regenerate the correct 16-bit SN using only the lower 4 bits.
For instance, in case of packet 2, only the lower 4 bits “0010” are transmitted. The receiving side, determining that the remaining upper 12 bits do not vary from packet 1, restores the SN to “0000 0000 0000 0010.” Since the CRC is added to every compressed packet, it is possible to check whether are stored header is a correct header.
Also, in the transmission of a packet 17, a carry occurs and the lower 5th bit changes from 0 to 1. As a result of this, the transmission cannot be correctly performed with only the lower 4 bits. So the packet 17 will transmit, for instance, the lower 6 bits “010000” of the SN, by which means the receiving side can regenerate the correct 16-bit SN.
Packet transmission using the ROHC will be explained with FIGS. 3 and 4. FIG. 3 is a block diagram showing the configuration of a conventional packet receiving apparatus. FIG. 4 is a sequence diagram showing the procedures of conventional packet transmission and reception.
First, as FIG. 4 shows, the transmitting side (the compressing side) transmits an IR packet containing static information, TS, SN, and CRC bits. Subsequently, an SO packet containing the lower bits SN′ of an SN and CRC bits are transmitted in succession. If the static information is not correctly received, the following information cannot be correctly received either. However, this can be prevented by transmitting an IR packet on a regular basis.
In the packet receiving apparatus shown in FIG. 3, predetermined radio receiving processing (for instance, down-conversion, A/D conversion, etc.) of a signal received via an antenna 601 takes place in receiving section 602, followed by a demodulation process of the signal after the radio receiving process. A packet subjected to the demodulation process is output to a header decompressing section 603, and the header is decompressed in the header decompressing section 603. With respect to the decompression of the header, as described above, the decompressing section 603 decompresses a compressed sequence number SN′ with reference to the context which is stored in a buffer 606 and which is the information of previously transmitted packets. More specifically, on the decompressing side (the receiving side), an SN is regenerated from an SN′ (the lower bits of an SN), the value of the TS (Time Stamp) contained in an RTP header is calculated from the SN, and an RTP header, UDP header, or IP header is reproduced from the static information, SN, and TS.
A packet containing a decompressed header is output to CRC section 604, and an error detection by CRC is performed in CRC section 604. When no error is detected by CRC, the packet is output as a received packet. Meanwhile, following the instructions from a context updating section 605, the contents of a buffer 606 is updated to the context of the received packet, that is to say, the header.
Thus, while the SN′ contains only the lower bits of an SN, because the upper bits have already been received on the decompressing side, an SN can be prefigured from the SN value of a reproduced packet, and therefore the entire SN can be regenerated. Even when this prefiguration fails, there generation of a false SN, which can be detected by CRC check, can be prevented.
A case that a bit error occurs in the header portion will be described next with FIG. 5. As FIG. 5 shows, when a bit error occurs in compressed packet 4 (SO), the bit error will be detected in the compressed packet 4 if a CRC detection is normally performed after the header has been decompressed on the decompressing side. It is then determined that an error has occurred in the header portion or in CRC bits, and the compressed packet 4 will be discarded.
Next a case of a bit error in an IR packet will be described with FIG. 6. As FIG. 6 shows, when an IR packet 6 is received, CRC is used to perform a bit error detection on the header of the IR packet. If a bit error is detected, the packet 6 will be discarded.
However, as FIG. 6 shows, the following problem exists when a packet is discarded in case of a bit error in an IR packet. That is to say, if a bit error is detected, this means that a bit error exists in any one or more of the static information, SN′, and CRC bits. Because of this, even when an error occurs in the static information alone (the non-compressed portion) and even when thus an SN′ is correctly received, the whole packet is discarded based on CRC results.